Management of the retention and/or discarding of stored data

ABSTRACT

Embodiments of methods, devices and/or systems for a method of managing the retention and/or discarding of stored data are described.

BACKGROUND

This disclosure is related to the management and/or discarding of storeddata.

One difficulty with state of the art technology relates to the abilityto manage the retention and/or the discarding of data that has beenstored, such as on a computing platform and/or on a storage areanetwork, for example. If the stored data is contained in an electronicfile, for example, deleting the file may not delete the stored data. Itmay be possible, depending at least in part on the system architectureand/or file management system, to recover the file that has beendeleted. In some circumstances, this may be undesirable, such as wherethe information relates to commercial secrets that a company or otherentity would like to permanently discard.

BRIEF DESCRIPTION OF THE DRAWINGS

Subject matter is particularly pointed out and distinctly claimed in theconcluding portion of the specification. The claimed subject matter,however, both as to organization and method of operation, together withobjects, features, and advantages thereof, may best be understood byreference of the following detailed description when read with theaccompanying drawings in which:

FIG. 1 is a schematic diagram illustrating an embodiment of a typicalarchitecture in which an embodiment of a method of managing theretention and/or discarding of stored data may be implemented;

FIG. 2 is a schematic diagram illustrating an embodiment of a treehierarchy for a set of keys for an embodiment of a method of managingthe retention and/or discarding of stored data;

FIG. 3 is a schematic diagram of an embodiment of a portion network thatmay employ an embodiment of a method of managing the retention and/ordiscarding of stored data;

FIG. 4 is a schematic diagram illustrating an embodiment of a filestructure for the embodiment shown in FIG. 3;

FIG. 5 is a schematic diagram of another embodiment of a network thatmay employ and embodiment of a method of managing the retention and/ordiscarding of stored data; and

FIG. 6 is a schematic diagram illustrating another embodiment of ahierarchy for a set of keys for an embodiment of a method of managingthe retention and/or discarding of stored data.

DETAILED DESCRIPTION

In the following detailed description, numerous specific details are setforth to provide a thorough understanding of the claimed subject matter.However, it will be understood by those skilled in the art that theclaimed subject matter may be practiced without these specific details.In other instances, well-known methods, procedures, components and/orcircuits have not been described in detail so as not to obscure theclaimed subject matter.

One difficulty with state of the art technology relates to the abilityto manage the retention and/or the discarding of data that has beenstored, such as on computing platforms, storage area networks, storagearrays (e.g., EMC, DMX), file servers (e.g., Windows 2003), and/orfilers (e.g., Net App filer), for example. If the stored data iscontained in an electronic file, for example, deleting the file may notdelete the stored data. It may be possible, depending at least in parton the system architecture and/or file management system, to recover thefile that has been deleted. In some circumstances, this may beundesirable, such as where the information relates to commercial secretsthat a company or other entity would like to permanently discard. Onepossible approach is to find all file fragments (including the filecopies in backups, disaster recovery locations, etc) and overwrite eachfragment several times with random and/or non-random data. This approachis usually impractical and/or time consuming.

FIG. 1 is a schematic diagram illustrating a typical architecture inwhich an embodiment of a technique to manage the retention and/ordiscarding of stored data may be implemented, although the claimedsubject matter is not limited in scope to this particular architecture.In this particular embodiment, FIG. 1 includes a first layer 110, asecond layer 120 and a third layer 130. Thus, for this particularembodiment, first layer 110 may make a request for services, such asthat data be written and/or read. Second layer 120 may receive therequest and may then fulfill it, assuming, for example, that it is ableto do so. There are a variety of services that may be provided by secondlayer 120. Frequently such services are data-related, such asauthentication, authorization, and/or data storage and/or retrieval,although these are just examples.

In this particular approach, layer two (also referred to as second layer120) may supplement or enhance services that may be available from layerthree (also referred to as third layer 130). Again, although the claimedsubject matter is not limited in scope to this approach or architecture,it is, nonetheless, a common one. For example, web proxy servers mayemploy this approach or architecture. One service that might also beprovided by layer two includes security. For example, this may includefirewall functionality, such as packet filtering, packet inspection(e.g., stateful and/or stateless), packet format validation, terminatingIPSec connections, and/or the like. Another service that might beprovided includes data encryption and/or decryption, as explained inmore detail hereinafter. Without loss of generality, in this context,encryption includes a process in which data is coded so that the contentof the data is not capable of being employed or understood by a personor a device without first being decoded back to the previous form orformat it had prior to being encrypted. Thus, decryption, in thiscontext, includes a process of decoding encrypted data back to the formor format it had prior to encryption.

Thus, in this particular example, if first layer 110 requests that databe written, second layer 120 may encrypt the data to be written. Thedata, once encrypted, may be stored by or at a third layer, such as 130.This is illustrated in FIG. 1 by 121. Likewise, second layer 120 may,upon another request for services by first layer 110, such as a readrequest, retrieve the stored, encrypted data from layer three, decryptit, and provide it to first layer 110. One potential advantage of anembodiment, such as previously described, is that encryption and/ordecryption of the data may be made transparent to third layer 130,although it is not necessary that this be the case, even for thisembodiment and, thus, the claimed subject matter is not limited in scopeto embodiments where this is so. Likewise, although the claimed subjectmatter is not limited in scope in this respect, the encryption may bealso made transparent to layer 1, e.g., the “consumer” of the services.Likewise, in another embodiment, any two layers, such as layer 1 andlayer 3, may reside on the same computing platform and even comprise thesame layer in some embodiments, although the claimed subject matter isnot limited in scope in this respect, of course. Nonetheless, for suchan embodiment, the encryption and/or decryption of data stored at or onthird layer 130 will not impact the operation of layer 130. In thisexample embodiment, layer 130 treats the data substantially the sameregardless of whether or not the data is encrypted. This may providesome benefits, such as making interoperability with other systemspossible. Of course, this is just one example of an embodiment of atechnique for managing the retention and/or discarding of stored dataand, as previously stated, the claim subject matter is not limited inscope to such an embodiment.

The following discussion details several possible embodiments foraccomplishing this, although these are merely examples and are notintended to limit the scope of the claimed subject matter. As describedabove, under some circumstances it may be desirable to discard storeddata and have the data discarded in a manner so that it may notpracticably be recovered. In this context, the term discard includes apractical inability to recover the data that has been discarded. Due atleast in part to the frequency in which users of today's computingplatforms tend to store files, such as spread sheets, word documents,e-mail and the like, multiple copies of such documents typically willexist on a variety of storage media and/or computing platforms.Likewise, additional copies may include tape backups, disaster recovery,local backups, etc. Thus, it may be extremely difficult, if not nearlyimpossible, with this type of behavior on the part of users, to discarda file. Likewise, even if there are no remaining copies of a specifiedfile, meaning that they have all effectively been “deleted,” on somecomputing platforms a file or other stored data is “deleted” simply bymarking it “deleted,” but the storage media is not “cleaned” by writingover the data so that it may no longer be recovered. For example, insome operating systems, such as “Data On Tap” produced by NetworkAppliance, sometimes new data does not overwrite prior data. Instead, anew sector of a disk or other storage media is written to and, thus,logically overwritten data is still possible to recover from thephysical medium (e.g. hard disk), and in addition, deleted files are notnecessarily overwritten. This may allow others, therefore, to recoverdata that has been stored and deleted.

Again, today's document retention policies in a variety of contexts makeit desirable to be able to discard stored data at specific instances ortimes. In one embodiment of a method of discarding stored data, a keythat was previously used to encrypt the stored data is discarded. Inthis context, a key includes any set of symbols, typically in the formof bits or bytes of data, employed to encrypt and/or decrypt a set ofdata using any currently known or to be later developed encryptiontechnique. Likewise, depending at least in part on the context, the termkey may be used to refer to multiple keys. To discard a particular fileor data set, the key used to encrypt this file or data set can bediscarded. In this context, the term data set or set of data is intendedto encompass any and all data storage, regardless of form, eithercurrently known or to be later developed. Thus, this may include, forexample, a file, a portion of a file, a sector or partition of a disk orLUN, a region of a database and/or any combinations thereof. Likewise,it may include storage on any type of media, such as CD-ROM, disk, flashmemory, etc., and/or in any physical form, such as electronic signals,optical signals, etc., whether currently known or to be later developed.Furthermore, discarding of the key may be accomplished in any one of anumber of ways.

For example, a key may be stored on a particular media and the media maybe discarded in some fashion or otherwise permanently destroyed. Oncethis happens, if a sufficiently strong encryption is employed, forexample, it is not practicable to recover the data. Thus, for anembodiment of a system for retaining and/or discarding stored data, ifit is desired that ease of administration be present, the same key maybe employed for all files and, hence, discarding the key in the mannerpreviously described results in discarding the stored data in files thathave been encrypted with that key.

As alluded to above, the key may be stored on conventional media, suchas a disk, CD-ROM, floppy disks, or on printed paper, for example. Thus,simply discarding this media or permanently destroying the mediadiscards the key, as is desired. Alternatively, a protected form ofmedia may be employed, such as a smart card, tamper resistant hardware,or the like. Such a medium of storage or piece of hardware, for example,may have the capable to keep a key relatively secure and may alsoinclude the capability to when instructed physically “delete” the key sothat it is at least practically not recoverable from the media orhardware and is, therefore, discarded. Here, again, destroying theprotected media ultimately discards the data. It may be worth noting, inthis context, that, depending upon the particular operating systemand/or computing platform, storing the key with the encrypted data maymake it difficult to successfully discard the stored data that has beenencrypted. Again, as previously described above, for the stored data tobe discarded, if the key has also been stored in a device that supportssnapshots (e.g., Network Appliances filer), it is practically difficultto erase the stored key by writing over the locations that contain thekey. It is likewise noted that where the key has been stored in multiplelocations, it is, of course, desirable to discard or permanently destroythose multiple copies.

If better granularity is desired, in an alternative embodiment, eachfile may be assigned a separate and distinct key, for example. In thisexample, discarding a key results in the data stored in the associatedfile likewise being discarded. One disadvantage of this approach,however, is that saving the key separately from the file, such as inflash memory or a proxy device, for example, may mean that a largeadditional amount of memory will be employed, e.g., to support a largenumber of files. Likewise, as indicated above, storing the key in thefile and/or together with the file may make it difficult to discard thekey.

In yet an alternate embodiment, a hierarchical key scheme may beemployed in which one or more keys may be manipulated to efficientlydiscard data. In this particular context, manipulating may includediscarding at least one of the keys in the hierarchy and/or it mayinclude changing at least one of the keys in the hierarchy. Here, thehierarchy has a tree structure, although the claimed subject matter isnot limited in scope in this respect. FIG. 2 is a schematic diagramillustrating one embodiment of such a key hierarchy. In this particularembodiment, a “root key” includes a key at a top of a hierarchy.Retention key(s) include(s) key(s) that are at least one step removedfrom a root key. Three retention keys, for example, are designated bynodes 220, 230 and 240 in FIG. 2. Likewise, here, the file keys are onelevel removed from the retention keys, although, of course, the claimedsubject matter is not limited in scope in this respect. For example,several additional layers of retention keys may separate the file keysfrom retention keys 220, 230, and 240. Here, however, the file keys aredesignated by nodes 260, 270, 280, 290, 215, 225, 235, 245 and 255.Likewise, additional layers of files and file keys may be present inwhich file keys higher in the hierarchy operate as retention keys forfiles lower in the hierarchy.

In this particular hierarchical structure, the root key designated bynode 210 in FIG. 2 is used to encrypt and/or decrypt the retention keys,designated by 220, 230 and 240. Likewise, the retention keys are, inturn, used to encrypt and/or decrypt the file keys that here are onestep removed from these retention keys. Therefore, retention key 220 isemployed to encrypt file keys 260, 270 and 280. Likewise, retention key230 is employed to encrypt file keys 290, 215 and 225. Furthermore,retention key 240 is used to encrypt file keys 235, 245 and 255. In thisparticular embodiment, therefore, the file keys may be stored togetherwith the file data. Thus, for this particular embodiment, the root keyand retention keys are stored separately.

For this particular embodiment, therefore, if it is desired to discardthe data contained in the files, for example, the root key may bediscarded, such as by permanently destroying the media in which it isstored, as previously described, for example, in connection with otherembodiments. Alternatively, if a particular set of files are to bediscarded, then the particular retention key for those files may bediscarded. For example, if it is desired to discard the files thatcorrespond to file keys 260, 270 and 280, then retention key 220 may bediscarded. Likewise, if it is desired to discard a single file (e.g. theone that uses key 270), then a new retention key is created, all filesthat we desire to keep (260, 280) have their file keys re-encrypted withthe new retention key, and the old one is deleted.

In the approach described above, although, of course, the claimedsubject matter is not limited in scope to this embodiment, it should beclear that a file is decrypted by identifying the appropriate retentionkey, using the root key to decrypt the retention key. using thedecrypted retention key to decrypt the file key and using the decryptedfile key to decrypt the stored encrypted data. In one particularembodiment, for example, an index of files associated with a retentionkey may be stored in metadata as well as the encrypted file keys.Likewise, as previously suggested, the root key may be used to encryptthe retention keys and may be stored separately.

Although the previously described embodiment illustrates a key hierarchywith three levels, in an alternative embodiment, as previouslysuggested, the number of levels to be employed is not restricted.Likewise, in an alternative embodiment, the hierarchy may not have apure tree-like structure or a structure that even resembles a tree. Forexample, in another implementation, the file key may be encrypted oncewith its retention key and once with the root key.

Likewise, in one embodiment, keys at different levels may be encryptedby keys from a prior level or such keys may be stored in plain textdepending upon the approach that is desired. If a key resides intamper-resistant hardware, it may be stored in “cleartext” to simplifyimplementation. In this context, cleartext refers to storing the data inthe form that ultimately is used for data processing, rather thanstoring the data in a form that is decrypted before use. It may bedesirable, for example, for the root key to be in “cleartext” inside atamper-proof hardware module. Each time a decryption operation isperformed, in one possible embodiment; this key may be used to decryptappropriate sets of keys from the hierarchy to use those keys to decryptthe file or data set. In addition, it may be possible for there to beseveral “root” keys. Also, in an embodiment, instead of using the keyfrom the previous level, one could use one or more keys from multiplelevels above to encrypt the key at the current level. Thus, depending,of course, upon the particular context, it might be beneficial for someof the keys to not be encrypted by a key in such an embodiment.Likewise, the keys may be stored as part of an encrypted file,separately from the file but on the same media, on separate(conventional) media, or on separate protected media, for example, suchas previously described.

With such a system, data (including key data), may be discarded bydiscarding the key used to encrypt it. It may also now be appreciatedthat a tree hierarchy, as previously described, may be implementedseamlessly in some embodiments. For example, if it desired to discardparticular files, those files may be “deleted” and reside in the recyclebin. Thus, in one embodiment, a computer platform may be configured toautomatically cycle through the files that have not been designated as“deleted,” re-encrypt those files keys with one or more new retentionkeys, and then discard one or more prior retention keys. If a file isencrypted with a “file key,” the file key may be encrypted with aretention key also stored in the file metadata. Thus, to discard files,a new retention key may be selected and used to re-encrypt the file keysof the files that one would like to retain. This might be advantageoussince re-encrypting a file key is typically more convenient thanre-encrypting a file. In an alternative embodiment, the file key(encrypted with a retention key or some other set of keys in ahierarchy) might reside on a different file system/device/array/etc.than the file itself. In this case, by re-encrypting the file key, onecan effectively discard a file or files even if these files reside on aWrite-Once-Read-Many (WORM) device or any other device that does notsupport writing over previously written data (e.g. Network Appliance'sSnap-Lock device). Likewise, in still another embodiment, a “history” ofrecently “deleted” retention keys may be retained to facilitate recoveryfrom erroneous deletions. Such recently deleted keys can be periodicallypurged.

As will now be appreciated, any system of key dependencies is includedwithin the scope of the claimed subject matter. The prior descriptionmerely describes several potential embodiments. Thus, in yet anotherembodiment, a hierarchy of keys may topologically comprise a directedacyclic graph, potentially with several “root” nodes, e.g., nodeswithout incoming edges, as illustrated, for example, in FIG. 6. In suchan embodiment, each node may correspond to a key, and a key may bestored with other keys, depending upon the particular embodiment,corresponding to some or all of the nodes that have outgoing edgespointing to the node corresponding to this key. Likewise, this key maybe stored as an encrypted key. In this particular embodiment, a key maybe encrypted with those keys corresponding to the parent nodes. Thus,typically, in such an embodiment, keys except root key(s) are storedencrypted. The keys in the middle of the hierarchy or graph or at the“leaves,” which correspond to nodes of a tree with no outgoing edges,are decrypted as appropriate for use. Likewise, in this embodiment, todecrypt a key involves decrypting its parents.

Instead of deleting data, such as a partition of a disk or LUN, afraction of a file, a storage region where a certain part of a databaseis stored, and/or a collection of any of the above, it is sufficient todiscard the associated keys. One may either discard the key used toencrypt the data, or its parent keys in the hierarchy, or parents ofparents, etc. In graph-theoretic terms, for this particular embodiment,it is sufficient to delete any node on one of the paths from a root tothe node to be discarded. However, discarding the key associated with anode in the hierarchy, for this embodiment, discards its children. Todiscard some of its children, a new key for the associated node may becreated and the children to be retained may be re-encrypted with thisnew value. Likewise, as previously alluded to, data may be discardedbased at least in part on a number of parameters, such as, for example,time, type of file, storage location, size of file, keywords in thefile, etc.

The embodiment immediately described above provides a system in which akey in a tree hierarchy depends on the keys pointing to it and the keysthat point to those keys, as shown, for example, in FIG. 6, referred tohere as an “AND” scheme. An alternative scheme may comprise one in whicha key may be recovered as long as there is at least one path from theroot that has not been discarded, referred to here as an “OR” scheme.Thus, depending on the particular embodiment, a mix of these approachesmay be used to both provide ways to discard data and also provideredundant key paths in situations in which it may prove useful. Thus, inthis context, in one embodiment, an “AND” scheme may, in one embodiment,involve using multiple encryptions, as previously discussed; whereas an“OR” scheme may, in one embodiment, involve encrypting a key with eachparent key separately and storing the encrypted copy separately, or,alternatively, allowing a certain set of parent keys to be available.For example, any M out of N parents keys may be available, where N isgreater than M, such as by representing the particular keys as apolynomial P(x) of degree M, evaluating P(x) for N distinct values of x,and then encrypting each result with the corresponding parent key. Inthis case, as long as M parent keys are present, e.g. Key 1 to Key M,for example, then the polynomial evaluated at M values may be recovered.From there the whole polynomial may be recovered and, hence, the key itrepresents. It is noted, of course, that this is simply one example of atechnique for implementation an “OR” scheme and the claimed subjectmatter is not limited in scope to employing this approach. Many otherapproaches are possible and are included within the scope of the claimedsubject matter.

In an alternate embodiment, a key management scheme may be employed toimplement a time-based retention and/or data discard policy, assuggested above with respect to a data retention and/or data discardpolicy based at least in part on a set of parameters. As one example, anew retention key for the files created during a given week may beapplied using a key hierarchy similar to the previously described keyhierarchy. Likewise, retention keys may be discarded based on age. Forexample, if one retains the most recently created 52 retention keys anddiscards any older retention keys files one year old are effectivelydiscarded. Likewise, if it is desired to extend the life of a particularfile one may re-encrypt the file key with another retention key, such asjust described. Thus, for the discarding of data that is based at leastin part on time, in one embodiment, “weekly retention keys” may beemployed. Of course, in alternative embodiments, this may be extended to“daily keys”, “yearly keys”, etc.

Likewise, in an alternative embodiment, a generalized key retentionscheme may provide for keys that map to any number of different timeintervals having any number of different durations. Likewise, such keysmay be different in “type”, in this context implying different retentionpolicies. Likewise, such keys may furthermore belong to different keyhierarchies. As one example, in such a system, a retention key may mapto a specified time interval, but on expiration may not be discardedunless administrative action occurs. Such an approach may be desirablein a scheme to ensure that stored data is not inadvertently discardedbefore it is confirmed that the stored data is to be discarded.Likewise, retention keys may expire in an order unrelated to when theywere created and/or may be employed to discard data from a specific timeinterval, while retaining data from other specific time intervals.Likewise, as previously described, for a given set of files, theretention key may be replaced by a new retention key so that the filekey is re-encrypted, effectively discarding those files in which thefile key was not re-encrypted.

In another embodiment, retention keys may correspond to a particulartime of creation and, therefore, have a time of expiration, but belongto different key hierarchies in which the hierarchies are related atleast in part to how long it is desired for the data to be retained. Inyet another embodiment, keys from different levels in a particular keyhierarchy may correspond to different levels of nested directories in afile system. For example, this may make it possible to discard adirectory with all of its contents by discarding the key that maps tothis directory from the hierarchy. Once the key is discarded, all keysencrypted by that key are discarded; hence all directories and filescontained in the target directory may be discarded.

The embodiments described above, it may be noted, are independent ofsystem architecture. Thus, it is not necessary that three layers beemployed and it is not necessary that encryption and/or decryption betransparent to a particular layer; of course, embodiments that includesuch features are also within the scope of the claimed subject matter,as previously described.

As previously described, one disadvantage of state of the art technologyis the ability, potentially, for an unauthorized entity or individual togain access to data stored on and/or being processed, such as may occurin networking, for example. In this context, networking is typicallyimplemented using at least two computing platforms. A computing platformrefers to a system and/or a device that includes the ability to processand store data in the form of signals. Thus, a computing platform, inthis context, may comprise hardware, software, firmware and/or anycombination thereof.

FIG. 3 is a schematic diagram illustrating an embodiment of a portion ofa network that may employ an embodiment of a method of managing theretention and/or discarding of stored data. Reference numerals 310, 320,330 and 340 denote units that access stored data. These may comprise,for example, clients, servers and the like. Reference numeral 360denotes a file server that stores encrypted data. Also depicted in FIG.3 is a directory of file server 360 that includes files respectivelydenoted 370, 380, and 390. These files, in this example, were encryptedby device 350. Therefore, as illustrated in FIG. 3, units 310-340comprise previously described layer one, device 350 comprises previouslydescribed layer two, and server 360 comprises previously described layerthree. Of course, this is merely an example embodiment and any one of anumber of different network architectures may be employed that arewithin the scope of the claimed subject matter.

For this particular embodiment, files 370-390 are illustrated in moredetail in FIG. 4. Here, the notation E(x,y) refers to an encryptionprocess where data denoted as x is encrypted with a key denoted y. Thus,as illustrated, the contents of file 370, denoted k1, has been encryptedby file key Fk1. However, also stored in file 370 is key Fk1 having beenencrypted by retention key Fr1. Likewise, retention key Fr1 has alsobeen employed to encrypt the keys for files 380 ad 390. These keys arerespectively denoted Fk2 and Fk3. Likewise, key Fk2 was employed toencrypt content k2 and Fk3 was employed to encrypt content k3. It isnoted that other retention keys and a root key are not shown in thisfigure, although, depending upon the particular embodiment, theassociated files and retention keys may follow a similar structure aspreviously described. For example, files 370-309 may also storeencrypted retention keys.

One approach or technique that may be employed to make unauthorizedaccess to data more difficult is the previously described embodiment. Itis worth noting, in this context, that data storage may take any one ofa variety of forms and the claimed subject matter is not limited inscope to any particular form of storing such data signals. Any and allmethods and/or techniques for storing data signals now known or that maysubsequently be developed are included within the scope of the claimedsubject matter. As is well-known, there are a variety of file typesand/or structures currently in use for storing data. In this context, afile includes stored data related at least in part by the particularformat in which the data is stored. As just one example, most clientsthat employ a Unix-based operating system use the Network File System(NFS) for remote file access. Sun® Microsystems introduced NFS in 1985.Since then, it has become a de facto standard protocol, used by over tenmillion systems worldwide. NFS is particularly common on Unix-basedsystems, but NFS implementations are available for virtually every modemcomputing platform in current use, from desktops to supercomputers.

Although the NFS file system and Unix-based operating systems arespecifically mentioned above, the issue of management of the retentionand/or discarding of stored data may arise for systems other than thosethat employ Unix or NFS. Essentially, for any instance in which data isstored, this issue may arise. Thus, the scope of the claimed subjectmatter is not limited to a particular hardware platform, softwareplatform, file type, data type, file structure, data structure,operating system, application, or the like. Furthermore, the claimedsubject matter is not limited to a particular implementation ofencryption or other security measures.

Referring, again, to the embodiment of FIG. 1, it is desired thatencryption and/or decryption be transparent to a third layer, although,again, this is just an example embodiment. While in a previouslydescribed embodiment, encryption and/or decryption was assumedtransparent to layer three, as previously indicated, this need not bethe case in an alternative embodiment. For example, communications maytake place between the layers to provide relevant and/or usefulencryption and/or decryption information to layer three. Thus,information and/or data may be passed that may reduce the processingload for layer two, for example.

As previously described, embodiments of the claimed subject matter arewell suited to a variety of networking applications and/or systems, suchas computer network systems, employing a variety of differenttopologies, including, for example, storage area networking (SAN),although, of course, the claimed subject matter is not limited in scopein this respect. In such an embodiment, although the claimed subjectmatter is not limited in scope in this respect, a configuration may beemployed in which management is accomplished of small, medium, or largenetworks comprised of storage devices, computers, other computingplatforms, and/or the like, that are communicatively coupled todissimilar storage devices, computers, other computing platforms, and/orthe like.

FIG. 5 is a schematic diagram of an example embodiment of acommunications network system 400 that may employ an embodiment inaccordance with the claimed subject matter. In this example, embodiment500 comprises a switched fabric 410 and a plurality of devices, such as420, 422, 424, and/or groups of devices, such as 434, 436, and 438, asindicated with respect to a logical loop 430, for example. References to“a switch” or to “switches” are intended to refer to a generic switch.In this context, then, the term switch includes a device having at leasta processor and memory in which the device is adapted to or has thecapability to route frames or packets between two or more separate,other devices. In general, a switched fabric, such as fabric 410, may becommunicatively coupled to various devices, such as, here, 420, 422, and424, and may operate as a switching network to allow these devices tocommunicate with one another. Devices 420, 422, and 424 may comprise anytype of device, such as, for example, a computing platform, a storagedevice, and/or the like, and may be communicatively coupled via fabric410 by employing point-to-point communications technology or techniques,as one example. In this particular embodiment, fabric 410 comprises avariety of communicatively coupled switches. In this particularembodiment, fabric 410 is also in communication with logical loop 430.Loop 430 here includes devices 434, 436 and 438. In this particularembodiment, loop 430 comprises an arbitrated loop with ring couplingsfor providing multiple nodes with the ability to arbitrate access toshared bandwidth. It is, of course, appreciated that this description ismerely an illustrative example and the claimed subject matter is notlimited in scope in any way to this particular embodiment.

As another example, one embodiment may be in hardware, such asimplemented to operate on a device or combination of devices, forexample, whereas another embodiment may be in software. Likewise, anembodiment may be implemented in firmware, or as any combination ofhardware, software, and/or firmware, for example. Likewise, although theclaimed subject matter is not limited in scope in this respect, oneembodiment may comprise one or more articles, such as a storage mediumor storage media. This storage media, such as, one or more CD-ROMsand/or disks, for example, may have stored thereon instructions, thatwhen executed by a system, such as a computer system, computingplatform, or other system, for example, may result in an embodiment of amethod in accordance with the claimed subject matter being executed,such as one of the embodiments previously described, for example. As onepotential example, a computing platform may include one or moreprocessing units or processors, one or more input/output devices, suchas a display, a keyboard and/or a mouse, and/or one or more memories,such as static random access memory, dynamic random access memory, flashmemory, and/or a hard drive, although, again, the claimed subject matteris not limited in scope to this example. It will, of course, beunderstood that, although particular embodiments have just beendescribed, the claimed subject matter is not limited in scope to aparticular embodiment or implementation.

In the preceding description, various aspects of the claimed subjectmatter have been described. For purposes of explanation, specificnumbers, systems and configurations were set forth to provide a thoroughunderstanding of the claimed subject matter. However, it should beapparent to one skilled in the art having the benefit of this disclosurethat the claimed subject matter may be practiced without the specificdetails. In other instances, well-known features were omitted and/orsimplified so as not to obscure the claimed subject matter. Whilecertain features have been illustrated and/or described herein, manymodifications, substitutions, changes and/or equivalents will now occurto those skilled in the art. It is, therefore, to be understood that theappended claims are intended to cover all such modifications and/orchanges as fall within the true spirit of the claimed subject matter.

1. A method of discarding stored data comprising: discarding a keypreviously used to encrypt said stored data.
 2. The method of claim 1,and further comprising: encrypting multiple sets of stored data usingmultiple keys; and encrypting said multiple keys so as to create atleast one hierarchy of key encryption dependencies among said multiplekeys; wherein discarding a key previously used to encrypt said storeddata includes discarding a key used to encrypt the key previously usedto encrypt said stored data.
 3. The method of claim 2, wherein said atleast one hierarchy of key encryption dependencies includes more thanone hierarchy level of key encryption dependencies.
 4. The method ofclaim 2, wherein discarding a key used to encrypt the key previouslysaid to encrypt said stored data includes discarding a key higher insaid at least one hierarchy than the key previously used to encrypt saidstored data.
 5. The method of claim 1, wherein said stored data iscontained in a file structure; said key comprising a file key; saiddiscarding a key comprising discarding said file key.
 6. The method ofclaim 5, and further comprising: encrypting said file key with aretention key; and wherein said discarding said file key comprisesdiscarding said retention key.
 7. The method of claim 6, wherein theencrypted file key is stored in said file structure.
 8. The method ofclaim 6, wherein the encrypted file key is stored separately from saidfile structure.
 9. The method of claim 8, wherein said retention key isalso encrypted and the encrypted retention key is also stored separatelyfrom said file structure.
 10. The method of claim 8, wherein storedseparately comprises stored via a separate storage medium.
 11. Themethod of claim 5, wherein the file key is stored in said filestructure.
 12. The method of claim 5, wherein the file key is storedseparately from said file structure.
 13. The method of claim 12, whereinstored separately comprises stored via a separate storage medium. 14.The method of claim 5, wherein said file structure is positioned in ahierarchy of file structures; and further comprising: encrypting saidfile key with a file key for a file structure higher in said hierarchyof file structures.
 15. The method of claim 14, wherein said discardingsaid file key comprises discarding said file key for said file structurehigher in said hierarchy.
 16. The method of claim 15, wherein saiddiscarding said file key for said file structure higher in the filehierarchy comprises discarding a root key.
 17. The method of claim 16,wherein said discarding said root key comprises discarding data storedin said hierarchy of file structures.
 18. The method of claim 15,wherein discarding said file key for said file structure higher in saidfile hierarchy comprises discarding data stored in multiple filestructures in said file hierarchy below said file structure higher insaid file hierarchy.
 19. The method of claim 14, wherein said hierarchyof file structures comprises multiple hierarchies of file structures;each of said hierarchies having a root key such that discarding the rootkey discards the data contents of the file structures of the particularhierarchy.
 20. The method of claim 14, wherein encrypting said file keywith a file key for a file structure higher in said hierarchy of filestructures includes encrypting said file key with at least some filekeys higher in said hierarchy along a path to a root key of saidhierarchy.
 21. A method of implementing data retention comprising:manipulating one or more keys employed to encrypt said data.
 22. Themethod of claim 21, wherein said manipulating includes discarding atleast one of said one or more keys.
 23. The method of claim 21, whereinsaid manipulating includes replacing at least one of said one or morekeys.
 24. The method of claim 23, wherein said one or more keys comprisea hierarchy of keys; said keys being related in said hierarchy throughan AND scheme, an OR scheme, or a combination of an AND/OR scheme. 25.The method of claim 23, wherein said one or more keys comprise ahierarchy of keys; wherein said manipulating includes discarding atleast one of said keys in said hierarchy.
 26. The method of claim 25,wherein said hierarchy of keys includes parent keys and children keys;and wherein discarding a parent key discards all of its children keys.27. The method of claim 23, wherein said one or more keys comprise ahierarchy of keys in which at least some of said keys in said hierarchyare encrypted; said replacing at least one of said one or more keyscomprises re-encrypting at least one of said at least some of said keyswith a different key.
 28. The method of claim 27, wherein said replacingat least one of said one or more keys comprises replacing said at leastone of said one or more keys based at least in part on at least oneparameter of a set of parameters, said set of parameters comprising:time, type of file, storage location, or size of file.
 29. The method ofclaim 28, wherein said at least one parameter of said set of parameterscomprises time.
 30. The method of claim 29, wherein said replacing saidat least one of said one or more keys takes place after a certain numberof weeks, months, or years.
 31. A method comprising: discardingencrypted data stored on a system; said system comprising a first layer,a second layer and a third layer, and said encrypted data residing onsaid third layer; wherein said first layer is capable of making read andwrite requests directed to said third layer; said second layer iscapable of performing services including encryption; and said thirdlayer is capable of performing services including data storage, saidencryption being transparent to said third layer.
 32. The method ofclaim 31, wherein said encryption is also transparent to said firstlayer.
 33. The method of claim 32, wherein at least any two of the threelayers reside on the same computing platform.
 34. The method of claim31, wherein said encrypted data is discarded by discarding a keypreviously used to encrypt said encrypted data.
 35. An articlecomprising: a storage medium having stored thereon instructions, thatwhen executed, result in performance of a method of discarding storeddata comprising: discarding a key previously used to encrypt said storeddata.
 36. The article of claim 35, wherein said instructions, whenexecuted, result in said method further comprising: encrypting multiplesets of stored data using multiple keys; and encrypting said multiplekeys so as to create at least one hierarchy of key encryptiondependencies among said multiple keys; wherein discarding a keypreviously used to encrypt said stored data includes discarding a keyused to encrypt the key previously used to encrypt said stored data. 37.The article of claim 36, wherein said instructions, when executed,result in said at least one hierarchy of key encryption dependenciesincluding more than one hierarchy level of key encryption dependencies.38. The article of claim 36, wherein said instructions, when executed,result in discarding a key used to encrypt the key previously said toencrypt said stored data including discarding a key higher in said atleast one hierarchy than the key previously used to encrypt said storeddata.
 39. The article of claim 35, wherein said instructions, whenexecuted, result in said stored data being contained in a filestructure; and said key comprising a file key; and said discarding a keycomprising discarding said file key.
 40. The article of claim 39,wherein said instructions, when executed, result in said method furthercomprising: encrypting said file key with a retention key; and whereinsaid discarding said file key comprises discarding said retention key.41. The article of claim 39, wherein said instructions, when executed,result in: said file structure being positioned in a hierarchy of filestructures; and said method comprising: encrypting said file key with afile key for a file structure higher in said hierarchy of filestructures.
 42. The article of claim 41, wherein said instructions, whenexecuted, result in said discarding said file key comprising discardingsaid file key for said file structure higher in said hierarchy.
 43. Thearticle of claim 42, wherein said instructions, when executed, result insaid discarding said file key for said file structure higher in the filehierarchy comprising discarding a root key.
 44. The article of claim 43,wherein said instructions, when executed, result in said discarding saidroot key comprising discarding data stored in said hierarchy of filestructures.
 45. The article of claim 42, wherein said instructions, whenexecuted, result in discarding said file key for said file structurehigher in said file hierarchy comprising discarding data stored inmultiple file structures in said file hierarchy below said filestructure higher in said file hierarchy.
 46. The article of claim 41,wherein said instructions, when executed, result in said hierarchy offile structures comprising multiple hierarchies of file structures; eachof said hierarchies having a root key such that discarding the root keydiscards the data contents of the file structures of the particularhierarchy.
 47. The article of claim 41, wherein said instructions, whenexecuted, result in encrypting said file key with a file key for a filestructure higher in said hierarchy of file structures includingencrypting said file key with at least some file keys higher in saidhierarchy along a path to a root key of said hierarchy.
 48. An articlecomprising: a storage medium having stored thereon instructions thatwhen executed, result in performance of a method of implementing dataretention comprising: manipulating one or more keys employed to encryptsaid data.
 49. The article of claim 48, wherein instructions, whenexecuted, result in said manipulating including discarding at least oneof said one or more keys.
 50. The article of claim 48, whereininstructions, when executed, result in said manipulating includingreplacing at least one of said one or more keys.
 51. The article ofclaim 50, wherein instructions, when executed, result in said one ormore keys comprising a hierarchy of keys; said keys being related insaid hierarchy through an AND scheme, an OR scheme, or a combination ofan AND/OR scheme.
 52. The article of claim 50, wherein instructions,when executed, result in said one or more keys comprising a hierarchy ofkeys; and said manipulating including discarding at least one of saidkeys in said hierarchy.
 53. The article of claim 52, whereininstructions, when executed, result in said hierarchy of keys includingparent keys and children keys; and discarding a parent key discards allof its children keys.
 54. The article of claim 50, wherein instructions,when executed, result in said one or more keys comprising a hierarchy ofkeys in which at least some of said keys in said hierarchy areencrypted; and said replacing at least one of said one or more keyscomprising re-encrypting at least one of said at least some of said keyswith a different key.
 55. The article of claim 54, wherein instructions,when executed, result in said replacing at least one of said one or morekeys comprising replacing said at least one of said one or more keysbased at least in part on at least one parameter of a set of parameters,said set of parameters comprising: time, type of file, storage location,or size of file.
 56. The article of claim 55, wherein instructions, whenexecuted, result in said at least one parameter of said set ofparameters comprising time.
 57. The article of claim 56, whereininstructions, when executed, result in said replacing said at least oneof said one or more keys taking place after a certain number of weeks,months, or years.
 58. An apparatus comprising: means for encrypting datawith one or more keys; and means for manipulating said one or more keysemployed to encrypt data.
 59. The apparatus of claim 58, wherein saidmeans for manipulating includes means for discarding at least one ofsaid one or more keys.
 60. The apparatus of claim 58, wherein said meansfor manipulating includes means for replacing at least one of said oneor more keys.
 61. The apparatus of claim 60, wherein said one or morekeys comprise a hierarchy of keys; said keys being related in saidhierarchy through an AND scheme, an OR scheme, or a combination of anAND/OR scheme.
 62. The apparatus of claim 60, wherein said one or morekeys comprise a hierarchy of keys; wherein said means for manipulatingincludes means for discarding at least one of said keys in saidhierarchy.
 63. The apparatus of claim 62, wherein said hierarchy of keysincludes parent keys and children keys; and wherein said means fordiscarding a parent key includes means for discarding all of itschildren keys.
 64. The apparatus of claim 60, wherein said one or morekeys comprise a hierarchy of keys in which at least some of said keys insaid hierarchy are encrypted; said means for replacing at least one ofsaid one or more keys comprises means for re-encrypting at least one ofsaid at least some of said keys with a different key.
 65. The apparatusof claim 64, wherein said means for replacing at least one of said oneor more keys comprises means for replacing said at least one of said oneor more keys based at least in part on at least one parameter of a setof parameters, said set of parameters comprising: time, type of file,storage location, or size of file.
 66. The apparatus of claim 65,wherein said at least one parameter of said set of parameters comprisestime.
 67. An apparatus comprising: a computing platform, said computingplatform adapted to manipulate one or more keys employed to encryptdata.
 68. The apparatus of claim 67, wherein said computing platform isfurther adapted to manipulate by discarding at least one of said one ormore keys.
 69. The apparatus of claim 67, wherein said computingplatform is further adapted to manipulate by replacing at least one ofsaid one or more keys.
 70. The apparatus of claim 69, wherein said oneor more keys comprise a hierarchy of keys; said keys being related insaid hierarchy through an AND scheme, an OR scheme, or a combination ofan AND/OR scheme.
 71. The apparatus of claim 69, wherein said one ormore keys comprise a hierarchy of keys; wherein said computing platformis further adapted to manipulate by discarding at least one of said keysin said hierarchy.
 72. The apparatus of claim 71, wherein said hierarchyof keys includes parent keys and children keys; and wherein saidcomputing platform is further adapted to discard children keys bydiscarding a parent key of said children keys.
 73. The apparatus ofclaim 69, wherein said one or more keys comprise a hierarchy of keys inwhich at least some of said keys in said hierarchy are encrypted; saidcomputing platform is further adapted to replace at least one of saidone or more keys by re-encrypting at least one of said at least some ofsaid keys with a different key.
 74. The apparatus of claim 73, whereinsaid computing platform is further adapted to replace at least one ofsaid one or more keys by replacing said at least one of said one or morekeys based at least in part on at least one parameter of a set ofparameters, said set of parameters comprising: time, type of file,storage location, or size of file.
 75. The apparatus of claim 67,wherein said computing platform comprises a switch.
 76. The apparatus ofclaim 67, wherein said computing platform is coupled in a network. 77.The apparatus of claim 67, and further comprising media to store saidone or more keys, wherein said media is capable of discarding at leastone of said one or more keys